High Speed Traffic Generator

ABSTRACT

There is disclosed a method of generating a data flow and a high speed packet generator. A sequence of packets to be transmitted may be defined. Generation of each packet in the sequence may be assigned to a respective transmit engine selected from a plurality of transmit engines. The plurality of transmit engines may generate respective assigned packets in parallel. Packets generated by the plurality of transmit engines may be coherently interleaved in the defined sequence to form the data flow.

RELATED APPLICATION INFORMATION

This patent is a continuation of U.S. patent application Ser. No.12/253,836, entitled Traffic Generator Using Parallel Coherent TransmitEngines, filed Oct. 17, 2008.

NOTICE OF COPYRIGHTS AND TRADE DRESS

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. This patent document may showand/or describe matter which is or may become trade dress of the owner.The copyright and trade dress owner has no objection to the facsimilereproduction by anyone of the patent disclosure as it appears in thePatent and Trademark Office patent files or records, but otherwisereserves all copyright and trade dress rights whatsoever.

BACKGROUND

1. Field

This disclosure relates to generating traffic for testing a network ornetwork device.

2. Description of the Related Art

In many types of communications networks, each message to be sent isdivided into portions of fixed or variable length. Each portion may bereferred to as a packet, a frame, a cell, a datagram, a data unit, orother unit of information, all of which are referred to herein aspackets.

Each packet contains a portion of an original message, commonly calledthe payload of the packet. The payload of a packet may contain data, ormay contain voice or video information. The payload of a packet may alsocontain network management and control information. In addition, eachpacket contains identification and routing information, commonly calleda packet header. The packets are sent individually over the networkthrough multiple switches or nodes. The packets are reassembled into themessage at a final destination using the information contained in thepacket headers, before the message is delivered to a target device orend user. At the receiving end, the reassembled message is passed to theend user in a format compatible with the user's equipment.

Communications networks that transmit messages as packets are calledpacket switched networks. In order to test a packet switched network ora device included in a communications network, it is often desirable togenerate network traffic having a data rate equal to the line rate ormaximum possible data rate of the network communication path or device.

A series of packets originating from a single source and having aspecific type of packet and a specific rate will be referred to hereinas a “stream.” A source may support multiple outgoing and incomingstreams simultaneously and concurrently, for example to accommodatemultiple packet types or rates. A source may be, for example, a port ona network interface. “Simultaneously” means “at exactly the same time.”“Concurrently” means “within the same time.” A plurality of concurrentstreams may be combined to form what will be referred to herein as a“flow”. A single flow may represent a plurality of packet types. Thestreams within a flow may be combined through interleaving. Theinterleaving may be balanced, unbalanced, and distributed among therepresented streams. The data rate of a flow may be equal to the linerate of a network communication path over which the flow is transmitted.Although the packets within a stream may be transmitted at the linerate, the average data rate of a stream over time may be much lower,since a plurality of interleaved streams may share the data rate of theflow.

One or more line-rate test flows may be required to thoroughly test apacket switched network or item of network equipment. Each test flow maybe composed of a plurality of interleaved streams representing multiplepacket types. To test a modern “triple play” network and networkequipment, a flow may contain simulated data, audio, and video streams.Since each test flow may simulate network traffic that might begenerated by a large plurality of sources during actual use of thecommunication network, the data rate of a test flow may exceed thecapacity of a single packet generator. Thus the generation of high speedtest flows may require combining the outputs of multiple packetgenerators.

DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a network environment.

FIG. 2 is a block diagram of a traffic generator which includes coherentparallel transmit engines.

FIG. 3 is a block diagram of an exemplary schedule and overlay engine.

FIG. 4A is a schematic diagram of exemplary packet forming data.

FIG. 4B is a schematic diagram of an exemplary packet sequence data.

FIG. 5A is a block diagram of an exemplary transmit engine.

FIG. 5B is a graphical representation of the operation of the exemplarytransmit engine of FIG. 5A.

FIG. 6 is a block diagram of an exemplary multiplexer unit.

FIG. 7 is a timing diagram for an exemplary packet generator.

FIG. 8 is a flow chart of a method for generating a traffic flow.

Throughout this description, elements appearing in block diagrams areassigned three-digit reference designators, where the most significantdigit is the figure number and the two least significant digits arespecific to the element. An element that is not described in conjunctionwith a block diagram may be presumed to have the same characteristicsand function as a previously-described element having a referencedesignator with the same least significant digits.

In block diagrams, arrow-terminated lines may indicate data paths ratherthan signals. Each data path may be multiple bits in width. For example,each data path may consist of 4, 8, 16, 32, 64, or more parallelconnections.

DETAILED DESCRIPTION

Description of Apparatus

Referring now to FIG. 1, there is shown a block diagram of a networkenvironment. The environment may include network test equipment 100, anetwork 190 and plural network devices 195.

The network test equipment 100 may be a network testing device,performance analyzer, conformance validation system, network analyzer,or network management system. The network test equipment 100 may includeone or more network cards 114 and a back plane 112 contained or enclosedwithin a chassis 110. The chassis 110 may be a fixed or portablechassis, cabinet, or enclosure suitable to contain the network testequipment. The network test equipment 100 may be an integrated unit, asshown in FIG. 1. Alternatively, the network test equipment 100 maycomprise a number of separate units cooperative to provide trafficgeneration and/or analysis. The network test equipment 100 and thenetwork cards 114 may support one or more well known standards orprotocols such as the various Ethernet and Fibre Channel standards, andmay support proprietary protocols as well.

The network cards 114 may include one or more field programmable gatearrays (FPGAs), application specific integrated circuits (ASICs),programmable logic devices (PLDs), programmable logic arrays (PLAs),processors and other kinds of devices. In addition, the network cards114 may include software and/or firmware. The term network cardencompasses line cards, test cards, analysis cards, network line cards,load modules, interface cards, network interface cards, data interfacecards, packet engine cards, service cards, smart cards, switch cards,relay access cards, and the like. The term network card also encompassesmodules, units, and assemblies that may include multiple printed circuitboards. Each network card 114 may provide one or more network ports. Theports of the network cards 114 may be connected to the network through acommunication medium 185, which may be a wire, an optical fiber, awireless link, or other communication medium. Each network card 114 maysupport a single communications protocol, may support a number ofrelated protocols, or may support a number of unrelated protocols. Thenetwork cards 114 may be permanently installed in the network testequipment 100 or may be removable.

The back plane 112 may serve as a bus or communications medium for thenetwork cards 114. The back plane 112 may also provide power to thenetwork cards 120.

The network devices 195 may be any devices capable of communicating overthe network 190. The network devices 195 may be computing devices suchas workstations, personal computers, servers, portable computers,personal digital assistants (PDAs), computing tablets, cellular/mobiletelephones, e-mail appliances, and the like; peripheral devices such asprinters, scanners, facsimile machines and the like; network capablestorage devices including disk drives such as network attached storage(NAS) and storage area network (SAN) devices; networking devices such asrouters, relays, hubs, switches, bridges, and multiplexers. In addition,the network devices 195 may include appliances, alarm systems, and anyother device or system capable of communicating over a network.

The network 190 may be a Local Area Network (LAN), a Wide Area Network(WAN), a Storage Area Network (SAN), wired, wireless, or a combinationof these, and may include or be the Internet. Communications on thenetwork 190 may take various forms, including frames, cells, datagrams,packets or other units of information, all of which are referred toherein as packets. The network test equipment 100 and the networkdevices 195 may communicate simultaneously with one another, and theremay be plural logical communications between the network test equipment100 and a given network device 195. The network itself may be comprisedof numerous nodes providing numerous physical and logical paths for datato travel.

Referring now to FIG. 2, an exemplary traffic generator 200 may includea schedule and overlay engine 220, a plurality of transmit engines 240A,240B, 240C, 240D, a multiplexer 260, a network interface unit 280, and acentral processing unit (CPU) 250. Within this description, the term“engine” means a collection of hardware, which may be augmented byfirmware and/or software, that performs the described functions. Whilethe exemplary traffic generator shown in FIG. 2 includes four transmitengines 240A-240D, the traffic generator 200 may have more or fewer (butnot less than two) transmit engines.

The CPU 250 may provide the schedule and overlay engine 220 withinstructions 252 to form a plurality of streams that may be interleavedto form the data flow 275. Each of the streams may include a sequence ofpackets. The packets within each steam may be of the same general typebut may vary in length and content. The schedule and overlay engine 220may perform multiple functions including scheduling the sequence ofpackets to be generated, and determining the length and variable contentfor each packet. The schedule and overlay engine 220 may then assigneach packet to one of the plurality of transmit engines 240A-240D. Thetransmit engines 240A-240D may work independently in parallel togenerate their assigned packets.

The schedule and overlay engine 220 may pass packet forming data 222required to generate each packet to the assigned transmit engine240A-240D. The packet forming data 222 passed from the schedule andoverlay engine 220 to the assigned transmit engine 240A-240D may includea stream identifier which also identifies the type of packet, a packetlength, variable data to be incorporated into the packet, andinstructions for filling the packet payload.

The schedule and overlay engine 220 may also pass packet sequence data224 to the multiplexer 260. The packet sequence data 224 may includedata identifying which of the transmit engines 240A-240D will contributethe next packet to the data flow 275. The multiplexer may coherentlycombine the packets formed by the transmit engines 240A-240D to form thedata flow 275. Within this description, the term “coherently” means “ina coherent manner”, where “coherent” has its conventional definition of“logically consistent and ordered”. Specifically, “to coherentlycombine” the packets generated by the transmit engines 240A-240D meansthat the packet are combined in an intended order that is determinedbefore the packets are generated.

The network interface unit 280 may convert the data flow 275 from themultiplexer 280 into the electrical, optical, or wireless signal formatrequired to transmit the data flow to the network under test 290 via alink 285, which may be a wire, an optical fiber, a wireless link, orother communication link.

The traffic generator 200 may include a CPU 250 which may contain aprocessor, a memory coupled to the processor, and various specializedunits, circuits, software and interfaces for providing the functionalityand features described here. The processes, functionality and featuresmay be embodied in whole or in part in software which operates on theprocessor and may be in the form of firmware, an application program, anapplet (e.g., a Java applet), a browser plug-in, a COM object, a dynamiclinked library (DLL), a script, one or more subroutines, or an operatingsystem component or service. The hardware and software and theirfunctions may be distributed such that some functions are performed bythe processor and others by other devices.

The CPU 250 may also generate a stream of packets 254 to the multiplexer260. The packets generated by the CPU 250 may represent stateful,interactive communication with some device within the network 290 using,for example, a TCP/IP stack implemented within the CPU 250.

The schedule and overlay engine 220, the transmit engines 240A-240D, theCPU 250, the multiplexer 260 and the network interface unit 280 mayinclude one or more of: logic arrays, memories, analog circuits, digitalcircuits, software, firmware, and processors such as microprocessors,field programmable gate arrays (FPGAs), application specific integratedcircuits (ASICs), programmable logic devices (PLDs) and programmablelogic arrays (PLAs). The physical partitioning of the components of thetraffic generator 200 may be different from the functional partitioningshown in FIG. 2, such that a given functional component or block may bedivided between two or more circuit devices and a single circuit devicemay contain all or portions of two or more functional components or allfunctional components.

The data flow to the network over the link 285 may have a maximum datarate, commonly termed the “line rate”. The data flow over the link 285may use encoding to facilitate transmission. The encoding may cause theline rate and the actual clock rate for the data to be different. Forexample, the actual clock rate of a 10 GHz link using 64 bit to 66 bitencoding may be 10.3125 GHz. The data rate for the path between themultiplexer 260 and the network interface unit 280 may be the same asthe line rate. The data rate for the paths between the transmit engines240A-240D and the multiplexer 260 may be less than the line rate. Thedata rate between the transmit engines 240A-240D and the multiplexer260, which may equal the rate at which packets are formed within thetransmit engines 240A-240D, may be equal to, or slightly greater than,the line rate divided by the number of transmit engines (4 in theexample of FIG. 2).

FIG. 3 shows a functional block diagram of an exemplary schedule andoverlay engine 320, which may be suitable for the schedule and overlayengine 220 in FIG. 2. The exemplary schedule and overlay engine 320 mayinclude a memory 322 to store a plurality of stream definitions, astream scheduler 324, a length generator 326, and overlay engine 328,and a transmit engine selector 330.

The memory 322 may be loaded with the definitions of a plurality ofstreams that constitute a testing session. The memory may be loaded fromthe CPU 250 shown in FIG. 2, or may be loaded from another computer (notshown) which may direct and monitor network tests. The definition ofeach of the plurality of streams may include data defining the streamtype such as TCP/IP, UDP/IP, or other type of stream. The definition ofeach of the plurality of streams may also include instructions forsetting various fields, such as address fields, within each packet ofthe stream, instructions for setting the length of each packet in thestream, and instructions for filling the body of the packets. Thedefinition of each of the plurality of streams may include the rates atwhich the packets comprising the stream are to be transmitted. Thedefinition of each of the plurality of streams may include other dataand instructions.

The stream scheduler 324 may determine the next packet to be formed byfirst determining the next stream to contribute a packet to the dataflow based on the stream definitions stored in the memory 322. To thisend, the stream scheduler may develop lists of departure times ordeparture intervals for the packets comprising the streams. These listsmay also be stored in the memory 322. Alternatively, the streamscheduler may develop linked lists of the transmission rates of theplurality of streams. The stream scheduler may include priority logic toresolve conflicts when two or more streams are scheduled to transmitpackets simultaneously.

After the stream scheduler 324 has identified the next stream and thenext packet to be formed, the length generator 326 may establish thelength of the next packet. The length of the next packet may be constantwithin the stream, may be random, may be calculated by adding apredetermined constant to the length of the previous packet in thestream, or may be established in some other manner.

After the stream scheduler 324 has identified the next stream and thenext packet to be formed, the overlay engine 328 may establish overlaydata for the next packet. The overlay engine 328 may determine theoverlay data concurrently or after the length generator determines thepacket length. The overlay data may be any data that is not constantbetween packets of the next stream. The overlay data may be establishedby calculation, such as by adding a predetermined number to thecorresponding data of the previous packet in the stream. The overlaydata may also be determined randomly, may be determined from a table ofstored values, or may be determined in some other manner as instructedby the stream definition for the next packet. One or more fields ofoverlay data may be established for each packet. Each field of overlaydata may be established in a different manner.

After the packet length and overlay data have been established, thetransmit engine selector 330 may select one of a plurality of transmitengines (not shown in FIG. 3) to form the packet. The transmit engineselector 330 may select any transmit engine that is idle. In thesituation where all of the plurality of transmit engines are occupiedforming packets, the transmit engine selector 330 may select the nextengine that will become available after completing the packet currentlybeing formed. The transmit engine selector 330 may provide packetforming data 332 necessary to form the packet to the selected transmitengine. The transmit engine selector 330 may be a first-in first-out(FIFO) buffer that temporarily stores the packet forming data 332. Inthis case, the next available transmit engine may pull the packetforming data 332 from the FIFO buffer.

Once a transmit engine has been selected, packet sequence data 334 maybe provided to a multiplexer (not shown in FIG. 3). The packet sequencedata 334 may include data required to coherently combine the next packetwith other packets to form the data flow

FIG. 4A illustrates packet forming data 432 that may be provided by aschedule and overlay engine, such as the schedule and overlay engine220, to a transmit engine. The packet forming data 432 may includestream identification data 432 a or some other data indicating the typeof packet to be formed.

The packet forming data 432 may also include the length 432 b of thepacket to be formed. However, in some cases the length of the packetsfor a stream (as defined by the stream ID 432 a) may be fixed and thelength 432 b may be omitted.

The packet forming data 432 may also include overlay data 432 c whichmay be any data that varies between the packets of the stream. Theoverlay data may include data that will be inserted into either theheader or the body of the packet. An example of the use of overlay datawould be to insert progressively or randomly changing IP addresses intoTCP/IP packets. Streams may be defined that simply transmit the samepacket repetitively, in which case the packet forming data may beomitted.

The packet forming data 432 may also include one or more payloadinstructions 432 d which tell the transmit engine how to fill thepayload, or body, of the packet. Payload instructions 432 d may instructthe transmit engine to fill the payload with a fixed content (i.e., allzeros or a fixed pattern in each byte), to fill the payload randomly, orto fill the payload in some other manner. Certain types of controlpackets may not have payloads, and the payload instructions 432 d may beomitted.

FIG. 4B illustrates packet sequence data 434 that may be provided by aschedule and overlay engine, such as the schedule and overlay engine220, to a multiplexer that combines the packets formed by a plurality oftransmit engines. The packet sequence data 434 may include a transmitengine ID 434 a identifying the transmit engine that has been assignedto form a packet. The transmit engine ID 434 a may be used by themultiplexer to place packets in the proper sequence for transmission.For example, the packet sequence data for a plurality of packets may beplaced in a FIFO buffer in the sequence that the packets are to betransmitted. A multiplexer, upon completing the transmission of acurrent packet may then pull the packet sequence data for the nextpacket from the FIFO buffer and use the transmit engine ID to determinewhich of a plurality of transmit engines is holding or has formed thenext packet.

The packet sequence data 434 for a packet to be transmitted may alsoinclude a stream identification 434 b, or other data identifying thetype of the packet, and the length of the packet 434 c. Alternatively, amultiplexer may determine either or both of the type of packet and thelength of the packet from the packet header and the corresponding typeand length data may not be included in the packet sequence data.

The packet sequence data 434 for a packet to be transmitted mayadditionally include a target transmit time 434 d. The multiplexer thatreceives the packet sequence data may use the target transmit time 434 dto control transmission of time-critical packets.

Referring now to FIG. 5A, an exemplary transmit engine 540, which may besuitable for use as the transmit engines 240A-240D, may include atemplate memory 544, a background engine 542, an overlay fill engine546, and a front end engine 548.

The template memory 544 may store templates for each of the packetstreams and/or packet types that may be formed by the transmit engine540. Each template may define a specific packet structure including thelength and content of the packet header, the location and content of anyfixed data fields, the location and extend of any fields to be filled byoverlay data, the location and type of any checksums or other calculatedfields, and other information necessary to form the packet. The templatememory 544 may be a read-only memory to store a fixed set of templates,or a writable memory where packet templates may be stored dynamically,or a combination of read-only and writable memories. Packet templatesmay be stored in a writable template memory 544 by a processor (notshown), for example, at the start of each test session.

Upon receipt of packet forming data including a stream ID or other dataindicating the type of packet to be formed, the background engine 542may retrieve the appropriate packet template from the template memory544. The background engine 542 may also extend or truncate the templateto set the packet length as indicated in the packet forming data.

After the appropriate template has been retrieved, the overlay fillengine 546 may insert the overlay data included in the packet formingdata into the appropriate fields of the packet as indicated by thetemplate. One of the background engine 542 and the overlay fill engine546 may fill the payload of the packet 545 as instructed in the packetforming data.

After the packet length has been set, the payload has been filled, andthe overlay data has been inserted, a front end engine 548 may completeforming the packet 545 by computing and inserting any requiredchecksums. For example, the front end engine 548 may compute an IPheader checksum, a TCP header checksum, and a CRC code or checksum forthe entire packet. The header checksums may be calculated and insertedinto the packet before the packet 545 is sent to a multiplexer (notshown), since the header checksums are commonly positioned in the packetbefore at least a portion of the data being checked. A checksum for anentire packet may be calculated while the packet is being sent and theninserted at the very end of the packet.

FIG. 5B graphically depicts the function of the exemplary transmitengine 540. The packet forming data 532 may include a stream ID 532 awhich may be used to select a packet template. The packet forming data532 may include overlay data 532 c which may be inserted into fieldswithin the packet header 545 a and/or payload 545 b, as defined by thepacket template and indicated by the dashed arrows. The stream ID 532 amay also be inserted into a field in the packet.

The packet forming data 532 may also include a packet length 532 b whichmay be used to set the length of the packet 545. Commonly, the length ofthe packet 545 may be set by adjusting the length of the payload 545 b.The packet forming data 532 may also include payload instructions thatmay be used to form content for the packet payload 545 b.

Referring now to FIG. 6, an exemplary multiplexer 660, which may besuitable for use as the multiplexer 260, may include a sequence dataFIFO buffer 662, a plurality of packet FIFO buffers 664A-664Dcorresponding to a plurality of transmit engines (not shown), and a dataselector 668. The exemplary multiplexer 660 may also include a statefultraffic FIFO buffer 666, a real time clock 667, and a time stamp engine669. Each FIFO buffer may include, for example, a memory with pointerregisters to indicate the address where new data may be written andwhere the oldest data in the memory data may be read. The exemplarymultiplexer 660 may receive packets 645 from the plurality of transmitengines and may interleave the packets into a data flow 675 sent to anetwork interface unit (not shown).

Packets 645 may be loaded into the packet FIFO buffers 664A-664D in theorder that the packets are formed by the respective transmit engines.The order in which the packets are formed may have been controlled suchthat packets stored within any one packet FIFO buffers 664A-664D do nothave to be reordered.

Packet sequence data may be loaded into the sequence data FIFO buffer662 in the order that packets are to be placed in the data flow 675,such that the packet sequence data next to be read from the packetsequence data FIFO buffer 662 may be the packet sequence data for thenext packet to be inserted into the data flow.

The data selector 668 may read packet sequence data for a packet fromthe sequence data FIFO buffer 662. The packet sequence data may includea transmit engine ID that identifies which transmit engine (not shown)formed the packet and thus which of the packet FIFO buffers 664A-664Dnow stores the packet. The data selector 668 may then read the packetfrom the identified packet FIFO buffer 664A, 664B, 664C, or 664D andsend the packet to the network interface unit (not shown) as part of thedata flow 675. As the data selector 668 completes sending the currentpacket, the data selector 668 may read the packet sequence data from thepacket sequence data FIFO 662 to repeat the cycle for the next packet.

Packets placed in the stateful traffic FIFO 666 may have priority overpackets stored in the packet FIFO buffers 664A- 664D. The data selector668 may delay reading a new packet from the packet FIFO buffers664A-664D in order to read and send a packet from the stateful trafficFIFO.

The exemplary multiplexer 660 may include a real time clock 667 and atime stamp engine 669. The time stamp engine 669 may add a time stamp tosome or all of the packets indicating the exact instant that each packetwas transmitted as part of the data flow 675. The time stamp added tothe packet may indicate a transmit time slightly later than real time tocompensate for known delays in the network interface unit. Depending onthe location of the time stamp within the packet, the time stamp engine669 may also correct one or more checksums within the packet. Todetermine the appropriate position for the timestamp and the checksumswithin a packet, the time stamp engine 669 may extract a stream ID orother data defining the type of the packet from the packet sequence dataassociated with the packet.

The packet sequence data for some or all of the packets may include atarget transmit time. The data selector 668 may compare the targettransmit time of a packet with the time provided by the real time clock667 and insert the packet into the data flow 675 at an appropriate time.The data selector 668 may insert the packet into the data flow 675 inadvance of the target transmit time to compensate for known delays inthe time stamp engine 669 and network interface unit (not shown).

FIG. 7 is a timing diagram illustrating the operation of an exemplarytraffic generator, which may be the traffic generator 200, thatcoherently combines the outputs of four parallel transmit enginesidentified as TE1-TE4. In this example, the traffic generator isgenerating an output flow including six streams, identified by theletters A-F. Each stream is composed of packets that are numberedsequentially. Each packet is identified by a letter-number pair, suchthat “A1” identifies the first packet in stream A. In this example, thelength of the packets in stream A is defined to be four times the lengthof the packets in the other five streams B-F. This example also assumesthat the desired packet sequence in the output flow is the first packetin each stream in order, followed by the second packet in each stream inorder, and so on (A1, B1, C1, D1, E1, F1, A2 . . . F2, A3 . . . F3,etc.).

The four horizontal bars at the top of FIG. 7, labeled TE1-TE4, aretiming diagrams showing the sequence in which the four transmit enginesgenerate packets. Each segment of each horizontal bar identifies thepacket being generated by the corresponding transmit engine during thecorresponding time period. Inspection of these diagrams shows that, inthis example, each packet in the sequence was assigned to an availabletransmit engine in a round robin manner. Packet A1 was assigned to TE1,B1 was assigned to TE2, C1 was assigned to TE3, and D1 was assigned toTE4. Since TE1 was still occupied generating A1, E1 was then assigned toTE2. F1 was assigned to TE3 and A2 was assigned to TE4. B2 was thenassigned to TE2 because TE1 was still occupied generating packet A1.

The twelve bars at the center of FIG. 7, labeled A1-F2, are timingdiagrams showing the status of twelve individual packets. Eachhorizontal bar has an un-shaded portion indicating the time when thepacket is generated, a cross-hatched portion (except for packet A1)indicating the time when the packet is stored in a queue, and a solidportion indicating the time when the packet is actually output as partof the output flow. Since this example assumed the use of four transmitengines to generate the packets, the maximum time allowed to generateeach packet (the un-shaded portion of each bar) is four times the lengthof the time required to transmit each packet (the solid portion of eachbar).

The bar at the bottom of FIG. 7 shows the timing of the output flow,which combines the twelve individual packets A1-F2. The output flow isshown, for example, with the packets transmitted contiguously. Dependingon network requirements, the output data flow may include gaps and/orsynchronization data between consecutive packets. The output flow mayalso include packets, such as packets representing stateful traffic,generated by a CPU independent of the transmit engines.

Additional and fewer units, modules or other arrangement of software,hardware and data structures may be used to achieve the processes andapparatuses described herein.

Description of Processes

Referring now to FIG. 8, a process for generating traffic in the form ofan output flow may start at 805 and finish at 865. Although the flowchart shows both a start 805 and finish 865, the process is cyclical innature and the actions from 815 to 860 may be repeated numerous times.

At 810, the definitions of a plurality of streams that constitute a testsession may be received from, for example, a computer that monitors andcontrols network tests. At 815, the next stream to contribute a packetto the output flow may be identified based on the stream definitions. At820 a length may be determined for the next packet in the streamidentified at 815, and at 825 overlay data for the next packet may becalculated. The length of the next packet determined at 820 may beconstant within the stream, may be random, may be progressive, or may bedetermined in some other manner. The overlay data determined at 825 maybe any data that is not constant between packets of the streamidentified at 815. The overlay data may be determined by calculation,such as by adding a predetermined number to the corresponding data ofthe previous packet in the stream identified at 815. The overlay datamay also be determined randomly, may be determined from a table ofstored values, or may be determined in some other manner.

At 830, one of a plurality of transmit engines may be selected to formthe next packet. The selected transmit engine may be any transmit enginethat is idle. In the situation where all of the plurality of transmitengines are occupied forming packets, the selected transmit engine maybe the next engine that will become available after completing thepacket currently being formed. The data required to form the next packetmay be pushed into a FIFO buffer and the next available transmit enginemay pull the data from the FIFO buffer.

Once a transmit engine has been selected at 830, packet forming datarequired to form the next packet may be provided to the selectedtransmit engine at 835 and the packet sequence data required tocoherently combine the next packet with other packets to form the dataflow may be provided to a multiplexer at 845. Packet forming data andpacket sequence data were previously described.

At 860 a decision may be made if the test session is complete or ifadditional packets must be formed. If additional packets are required,the process returns to 815 and repeats until all packets have beenformed. If all packets have been formed, the process terminates at 865.

At 840, the selected transmit engine may form the next packet asdirected by the packet forming data provided at 835. Forming the nextpacket may include retrieving a stored template for the appropriatestream, setting the length of the packet, filling fields of the packetwith variable data included in the packet forming data, and calculatingone or more checksums. At 850, the next packet may be multiplexed withother packets generated by the same or other transmit engines in thesequence indicated by the packet sequence data provided at 845. At 855,the output flow may be transmitted over a link to a network or deviceunder test.

Closing Comments

Throughout this description, the embodiments and examples shown shouldbe considered as exemplars, rather than limitations on the apparatus andprocedures disclosed or claimed. Although many of the examples presentedherein involve specific combinations of method acts or system elements,it should be understood that those acts and those elements may becombined in other ways to accomplish the same objectives. With regard toflowcharts, additional and fewer steps may be taken, and the steps asshown may be combined or further refined to achieve the methodsdescribed herein. Acts, elements and features discussed only inconnection with one embodiment are not intended to be excluded from asimilar role in other embodiments.

For means-plus-function limitations recited in the claims, the means arenot intended to be limited to the means disclosed herein for performingthe recited function, but are intended to cover in scope any means,known now or later developed, for performing the recited function.

As used herein, “plurality” means two or more.

As used herein, a “set” of items may include one or more of such items.

As used herein, whether in the written description or the claims, theterms “comprising”, “including”, “carrying”, “having”, “containing”,“involving”, and the like are to be understood to be open-ended, i.e.,to mean including but not limited to. Only the transitional phrases“consisting of” and “consisting essentially of”, respectively, areclosed or semi-closed transitional phrases with respect to claims.

Use of ordinal terms such as “first”, “second”, “third”, etc., in theclaims to modify a claim element does not by itself connote anypriority, precedence, or order of one claim element over another or thetemporal order in which acts of a method are performed, but are usedmerely as labels to distinguish one claim element having a certain namefrom another element having a same name (but for use of the ordinalterm) to distinguish the claim elements.

As used herein, “and/or” means that the listed items are alternatives,but the alternatives also include any combination of the listed items.

1. A method of generating a data flow, comprising: defining a sequenceof packets to be transmitted assigning each packet in the sequence to arespective transmit engine selected from a plurality of transmit enginesthe plurality of transmit engines generating respective assigned packetsin parallel coherently interleaving packets generated by the pluralityof transmit engines in the defined sequence to form the data flow. 2.The method of generating a packet flow of claim 1, further comprising:storing definitions for a plurality of packet streams determining, fromthe stored definitions, the packet sequence, the packet sequenceindicating the order in which packets from the plurality of packetstreams are to be interleaved to form the data flow identifying a nextpacket in the packet sequence assigning the next packet to one of theplurality of transmit engines.
 3. The method of generating a packet flowof claim 2, wherein assigning the next packet further comprises:determining packet forming data for the next packet providing the packetforming data to the assigned transmit engine.
 4. The method ofgenerating a packet flow of claim 3, wherein generating the next packetcomprises: the assigned transmit engine generating the next packetbased, at least in part, on the packet forming data.
 5. The method ofgenerating a packet flow of claim 1, wherein coherently interleavingfurther comprises: storing the packets generated by the plurality oftransmit engines in a corresponding plurality of FIFO buffers selectingpackets for transmission from the plurality of FIFO buffers inaccordance with the defined sequence.
 6. The method of generating apacket flow of claim 1, wherein defining a sequence of packets includessetting target transmit times for at least some of the packets, andwherein coherently interleaving includes transmitting packets at therespective target transmit times.
 7. A traffic generator to transmit adata flow, comprising: a plurality of transmit engines to generatepackets in parallel a scheduler to define a sequence of packets to betransmitted and to assign generation of each packet in the sequence to arespective transmit engine selected from the plurality of transmitengines a multiplexer to coherently interleave packets generated by theplurality of transmit engines in the sequence defined by the schedulerto form the data flow.
 8. The packet generator of claim 7, wherein thescheduler provides packet forming data for each packet to the respectivetransmit engine each transmit engine generates respective assignedpackets based, at least in part, on the packet forming data receivedfrom the scheduler.
 9. The packet generator of claim 8, wherein thepacket forming data for each packet includes one or more of a streamidentifier, a packet length, overlay data, and payload instructions. 10.The packet generator of claim 7, wherein the multiplexer furthercomprises: a plurality of FIFO buffers, each FIFO buffer coupled toreceive packets from a corresponding one of the plurality of transmitengines a data selector to retrieve packets from the plurality of FIFObuffers in the sequence defined by the scheduler to form the data flow.11. The packet generator of claim 10, wherein the multiplexer furthercomprises: another FIFO buffer coupled between the scheduler and thedata selector to hold data indicative of the sequence defined by thescheduler.
 12. The packet generator of claim 10, wherein the multiplexerfurther comprises: a real time clock a timestamp engine coupled betweenthe data selector and a network interface unit to add a timestamp inaccordance with the real time clock to at least some of the packetsprior to transmission via the network interface unit.
 13. The packetgenerator of claim 7, wherein the multiplexer outputs the data flow at afirst data rate, and the transmit engines generate packets at a seconddata rate lower than the first data rate.
 14. The packet generator ofclaim 13, wherein the second data rate is equal to the first data ratedivided by a number of transmit engines in the plurality of transmitengines.
 15. A machine readable storage medium storing configurationdata which, when used to configure a programmable hardware device,causes the programmable hardware device to be configured to include atraffic generator, comprising: a plurality of transmit engines togenerate packets a scheduler to define a sequence of packets to betransmitted and to assign generation of each packet in the sequence to arespective transmit engine selected from the plurality of transmitengines a multiplexer to coherently interleave packets generated by theplurality of transmit engines in the sequence defined by the schedulerto form a data flow.
 16. The machine readable storage medium of claim15, wherein the scheduler provides packet forming data for each packetto the respective transmit engine each transmit engine generatesassigned packets based, at least in part, on the packet forming datareceived from the scheduler.
 17. The machine readable storage medium ofclaim 16, wherein the packet forming data for each packet includes oneor more of a stream identifier, a packet length, overlay data, andpayload instructions.
 18. The machine readable storage medium of claim15, wherein the multiplexer further comprises: a plurality of FIFObuffers, each FIFO buffer coupled to receive packets from acorresponding one of the plurality of transmit engines a data selectorto retrieve packets from the plurality of FIFO buffers in the sequencedefined by the scheduler to form the data flow.
 19. The machine readablestorage medium of claim 18, wherein the multiplexer further comprises:another FIFO buffer coupled between the scheduler and the data selectorto hold data indicative of the packet sequence.
 20. The machine readablestorage medium of claim 18, wherein the multiplexer further comprises: areal time clock a timestamp engine coupled between the data selector anda network interface unit to add a timestamp in accordance with the realtime clock to at least some of the packets prior to transmission via thenetwork interface unit.
 21. The machine readable storage medium of claim15, wherein the multiplexer outputs the data flow at a first data rate,and the transmit engines generate packets at a second data rate lowerthan the first data rate.
 22. The machine readable storage medium ofclaim 21, wherein the second data rate is equal to the first data ratedivided by a number of transmit engines in the plurality of transmitengines.